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ABSTRACT 

There  is  a  substantial  group  of  professionals,  scientists, 
engineers,  and  managers  who  are  justifiably  reluctant  to  use 
computer  networks  such  as  the  ARPANET,  '"his  phenomenon  continues 
despite  the  fact  that  they  recognize  some  of  the  ber.°fits  cf 
computational  assistance,  that  they  ha''e  had  experience  usir :g 
computer  systems,  and  that  they  have  access  to  such  a  network. 
Their  reluctance  usually  stems  from  the  feeling  that  the  very 
great  effort  required  to  familiarize  themselves  with  r.ew 
machines  and  systems  is  not  justified  by  the  occasional  or 
intermittent  nature  of  their  computational  problems.  In  learning 
t.o  use  a  new  system,  a  large  part,  of  the  famil iari  ze t i  on  effort 
is  spent  In  trying  to  learn  to  use  a  new  text  editing  program. 
If  such  a  utility  program  were  standardized  and  made  available 
on  all  of  the  machines  on  the  network,  a  large  obstacle  to  the 
efficient  use  of  such  systems  migvt  be  removed.  The  design  of 
such  a  system,  a  Standard  Line  EPitor  called  "SLED"  is  proposed 
here . 
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BACKGROUND 


The  United  States  Navy  is  currently  -  or.d  r  ~  t  in  r  en 
experiment  to  determine  the  effectiveness  of  cc^ruter  retvor/ire 
in  providing  the  computing  support  required  by  thc  \a'-y 
laboratories.  In  the  course  of  this  experiment,  si  f.  r.if  i  car.  t 
resources  of  the  laboratories  are  heir.??  organized  into  a  "aAw 
Laboratory  Computer  Network”  or  ’NALCON”  (1'  (?)  tc  prorote  t  :.e 
efficient  use  of  the  physical  and  logical  resources  of  the  .Navy 
laboratories  . 

While  the  NALCCN  system  was  being  implemented,  it  was 
recognized  that  software  technology  often  pcses  greeter  Erobl°mt 
than  does  the  hardware  design  and  construction .  In  response  tc 
this,  the  Navy  Laboratory  Computer  Committee  (NICC)  forrQ1  a 
Software  Technology  Working  C-roup.  It  is  the  goal  cf  this  grcnr 
to  address  the  specific  software  problems  of  !ULCC.\’ ,  and  tc 
consider  t>e  larger  problems  of  software  technology  in  the  Navy 
computing  community. 

After  a  series  of  meetings,  the  Software  Technology  Vrrkirm 
Croup  reported  ( c)  that  the  number  and  diverse  nature  of  text 
editor  programs  constituted  a  significant  obstacle  (both  real 
ard  psychological)  to  the  efficient  use  of  network  resources.  It 
was  suggested  that  either  a  standard  editor  be  developed,  or 
that  all  network  computers  contain  editors  with  a  standard 
subset  of  commands. 
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Subsequently,  work  was  undertaker,  at  the  Navel  Fcs'-radu*  t® 
School  to  determine  the  desirable  cha  racteri  st  i  ~s  vni~n  suer,  c” 
editor  should  display,  and  to  define  c7”  specify  th®  -ser 
interface  for  this  proposed  standard  editor.  ?h®  "esul^s  or  this 
effort  are  described  below. 

PHILOSOPHY 

Eefore  we  describe  the  proposed  standard  ®d 1 1  cr  ,  it  i «. 
appropriate  that  several  non-techr.  i^al ,  philosophical,  asrects 
of  the  editor  design  be  discussed. 

It  should  be  recognized  that  any  editor  wil1  certain  tore 
characteristics  which  significant  portions  of  the  rorruts:  user 
community  will  find  objectionable.  The  implem®r ta t i cn  r f  text 
editor  features  is  often  a  matter  of  personal  tacte.  vou  "?r.  not 
pleas®  all  of  the  people  all  of  the  tire.  *e  believe  that  the 
proposed  editor  is  well  thought  out,  and  is  based  upon  the 
experience  of  thousands  of  computer  users  spanri’-g  well  over  a 
decade  of  network  ard  timesharing  experience.  Our  solution  is 
certainly  not  unique.  There  are  other  solutions.  We  have 
confidence  that  ours  is  or  ®  of  the  better  possibilities,  ard 
should  seriously  be  considered  as  a  standard. 

With  regards  to  the  specification  itself,  ir  th®  fallowing 
sections  we  will  attempt  to  describe  the  editor  i  ’"forma  lly, 
using  a  mixture  of  two  techniaues.  The  description  will  mt  be  a 
rigorous  sped  f  i  oati  on  in  the  software  engineer!  r.g  ser.sd  ncr 
will  it  b®  a  "users  view”  of  the  editor.  Hy  -'ombi  r.i  r.g  asneds  of 


these  two  techniques  -  specif  icat  i  or.s  and  a  "users  i »> t  roduc  t  i ° r  " 
type  description  of  the  editor  -  we  hope  to  bcth  de'~ribe  the 
editor  in  sufficient  detail  that  it  can  be  irpierprt.o(j  t  a~l  :’1  v° 
the  readers  a  "feel"  for  using  the  editor.  V.e  a<;>  t'-at  t'"c 
reader  keep  in  mind  the  goal  of  the  standard  editor  rrojor*,  and 
this  philosophy  while  reading  the  remainder  of  thi^  paper. 

TEE  GOALS  CF  A  "STANDARD  ILITOP" 

The  goal  of  th*3  Standard  Editor  project  is  to  defln°  and 
develop  a  simple  and  easy  to  use  text  editor  prop-rar  whi"h  car. 
be  readily  implemented  or  a  wide  variety  of  host  ma-hir^*  ard 
operating  systems.  This  objective  and  the  rrrputer  network 
context  of  its  development  allow  further  definition  of  SIID 
requirements . 

The  usage  envisioned  for  SIET  is  twofold-  casual  use  oy 
persons  local  to  the  host*  and.  use  by  occasional  network  guests 
of  the  host.  Such  a  simple,  basic  editor  car  not  and  should  rot 
attempt  to  replace  the  principal  system  °ditor  programs 
available  on  the  host  machines.  Since  the  ^rope  of  usa^e  is  thus 
^educed,  r.o  attempt  need  be  made  to  design  SLED  to  be  all 
powerful  (and  h.Pnce  complex).  SLED  only  need*;  to  support  tr.e 
basic  text  editing  functions,  and  if  tnese  functions  are 
supported  in  a  well  deslgred,  wpII  documented,  °asy  to  use 
implementation,  the  basic  goals  of  the  project  car  be  fulfilled. 

The  lirlt^d  scope  also  allows  implementations  to  be 
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accomplished  without  undue  attention  to  Questions  of  execution 
efficiency  which  are  vital  in  the  design  of  a  principal  system 
editor.  Thus  implementations  can  be  realized  usir.c  higher  level 
computer  programming  languages,  with  erphasis  o^  portability  ?rJ 
system  independence. 

The  wide  variety  of  users  anticipated,  ar.d  the  la  rf.°  nnrbtr 
of  implementations,  requires  several  one  rac  t  er  i  s  t  i  cs  of  th* 
editor  to  be  present  in  all  its  implementations.  Certainly  all 
the  implementations  must  be  as  nearly  uniform  (in  terrs  of  the 
user  interface)  as  current  software  technology  permits.  In 
designing  the  editor,  the  usage  and  ecmmards  must  be  kept 
simple.  The  commands  must  function  "intuitively"  and  be  °  c  s  y  tc 
learn  and  remember.  Further,  no  special  terminal  character  set 
or  line  speed  assumptions  can  be  made. 

SPECIFYING  THE  EDITOR 

From  these  general  requirements,  a  "“ere  detailed 
specification  was  developed.  Great  effort  was  made  to  ke°p  the 
editor  simple  (from  the  user's  point  of  view).  Of  secondary 
importance  was  machine  and  system  independence,  end  portability 
of  the  implementations.  The  resultant  specif ica t  ions  are 
described  informally  (from  the  point  of  view  of  the  user)  below. 

The  constraints  upon  terminals  and  line  speeds,  coupled 
with  the  restricted  nature  of  the  editor  led  as  to  select  a 
"line  oriented  editor"  approach.  \*  i  th  the  addition  of  a  logical 
line  terminator  character  and  a  simple  display  function,  line 
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oriented  editors  have  been  shown  to  funrtion  efficiently  wits  a 
variety  of  terminals  using  a  wide  rang0  of  line  speeds  in  a  tlT<= 
sharing  environment  (4), (5). 

A  minimum  set  of  commands  consistent  witn  °»sy  use  3e?r 

selected  (5), (6).  These  commands  draw  their  mrerc"!'  sy^tcls 
from  the  first  letters  of  their  key  words  faker.  in  rmrrel 
Fngiish  language  order.  For  example,  the  command  to  "insprt  text 
<A>fter  <L>ine  5"  is  "AI5”.  There  was  some  desire  to  limit  the 
mnemonics  to  single  characters.  While  this  would  decrease  the 
total  number  of  key  strokes  required  in  an  edit  session,  the 
decrease  is  a  small  percentage  of  the  total  number  of  u^.ractPrs 
typed.  The  advantages  of  natural  English  language  command 
ordering  combined  with  the  relative  independence  from  racy  other 
editors  which  use  single  character  commands  (hence  decreasing 
the  chances  of  confusion  end  error  for  pprsons  inadvertently 
reverting  to  other  editor  commands)  was  considered  to  outweigh 
the  advantages  of  exclusive  use  of  singlp  character  mnemonics. 

There  are  a  total  of  eleven  commands,  only  seven  of  which 
need  he  used  to  obtain  full  text  editing  capability.  These 
eleven  commands  can  be  rougnly  subdivided  into  five  basic 
groups : 

1.  Line  Insertion  and  Peplacemert  commands  (two  commands) 

2.  String  Replacement  commands  (ore  basic  command) 

3.  String  Search  commands  (one  basic  cormand) 

4.  Terminal  Output  commands  (four  cormends; 

5.  Control  commands  (three  commanas) 

These  commends  ere  more  fully  described  ir.  Table  1. 
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Sirce  many  of  the  prospective  SLED  users  ar°  orlv 
occasional  users  of  computer  systerrs,  initiation.  cf  all 
implements  t  i  ons  should  he  uniformly  c  Oerter.'' ed  by  typing  only 
"SLED<Carrage-return">"  after  linking  and  loa'gin^  i"tc  the 
network  host  machine.  At  this  point,  th®  casual  user  may  ask  for 
a  menu  to  refresh  his  memory  as  to  the  basic  commands  and  their 
format  via  the  "h1"  command.  (See  Figure  1  for  an  example  of  the 
s'fOenu  output.)  The  possibility  of  SLED  users  equirpec  with  low 
*^peed  terminals  or  low  speed  lines  r®quir°s  that  this  message  be 
kept  brief.  Two  incorrectly  formatted  requests  in  series  will 
aut o^a t ica 1 ly  cause  the  execution  of  a  <w>eru  cormard. 

A  more  experienced  user  may  directly  execute  th®  <V>®rsicn 
command  which  will  print  a  brief  version  identification,  the 
name  and  telephone  numbers  of  consultants  who  car  provide  seme 
help  if  required,  and  will  explicitly  identify  any  fectures  of 
the  editor  which  are  required  by  the  local  system.  A  sarple  of 
the  <V>ersion  output  is  shown  in  Fieure  2. 

The  editor,  like  many  other  editors,  features  essentially 
two  modes:  Edit  command’  mode  and  text  Insert’  mode.  SLEI, 
when  initialized,  starts  in  "Fdit  rormand"  mode,  end  requests  er 
edit  command  from  the  user's  console  by  transmitting  to  the  user 
the  prompt  "F>".  This  prompt  will  also  be  transmitted  following 
the  successful  execution  of  any  edit  command  message  lire 
(except  one  containing  the  ’VOuit"  command)  and  the  editor  will 
await  further  instructions.  Following  this  prompt  the  user  can 
®nter  any  command  shown  in  Tablp  1.  Commands  and  their  fields 
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can  be  separated  by  any  valid  logical  message  terminator  (see 
Figure  2).  The  character  "Carriage  return"  always  serves  as  a 
message  terminator.  One  other  character  1«  provided  fer  use  as  a 
message  terminator,  and  this  Is  chengible  at  the  direction  of 
the  user  via  the  <C>hanfce  ^T^ermina to r  command.  This  fea turc 
allows  the  "stacking"  of  editor  commands  within  a  single 
physical  line  of  input.  This  feature  is  demonstrated  belov,  and 
is  extremely  convenient  in  a  network  operating  environment.  If 
the  command  executed  by  the  user  causes  the  editor  to  enter  th° 
"text  Insert"  node,  the  editor  will  prompt  the  user  for  data 
with  the  symbol  "l>".  All  text  entered  after  these  prompts  will 
be  copied  directly  to  the  text  file,  and  will  not  be  interpreted 
as  edit  commands.  The  only  way  to  return  from  the  "text  Insert" 
mode  to  the  "Edit  command"  mode  is  by  entering  a  single  message 
consisting  of  ONLY  a  period 

While  these  two  prompts  are  somewhat  inconvenient  to  users 
desiring  to  operate  in  a  "non-echo”  mode,  they  are,  in  general, 
necessary  for  two  reasons.  They  are  useful  in  confirming  to  the 
(inexperienced)  user  which  mode  he  is  currently  in;  ar.d  they  are 
vital  in  systems  which  do  not  save  data  buffers  as  a 
synchronization  mechanism  (for  example  a  PDP-11  using  the  PSX-11 
operating  system  which  does  NOT  allow  "type  ahead"  of  logical 
read  commands). 

These  modes  and  their  functions  can  be  better  understood 
from  the  following  example  of  SLED  usage: 
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EXAMPLE  1:  USING  SLED  TO  CREATE  A  FILE 
(Fror  a  UNIX  Like  implementation) 

*SLED 

E>0 

f ilename?>NEW. f lie 
-creating  file  "NEW.file"- 
E>AL0 

O  First  text  line 
I>Second  text  line 
I>  Third  text  line 
I>. 

F>L1 ,3 

1  First  text  line 

2  Second  text  line 

3  Third  text  line 
F>Q 

% 

In  the  above  example,  the  SLEr  editor  was  used  to  create  a 

new  text  file,  and  to  enter  three  sirpl<=>  lin<=>s  of  text.  Use  of 

the  logical  message  terminator  key  (if  available)  ran 

significantly  simplify  the  use  of  the  editor.  This  key  allows 

several  command  lines  (either  edit  commands  or  insert  lines)  te 

be  entered  on  a  single  physical  line  from  the  terminal.  Example 

2  shows  the  use  of  the  logical  message  terminator  key  (*hovn  as 

"$”)  to  "stack”  several  editor  commands  into  a  single  line  of 

input.  The  effect  of  the  commands  shown  in  this  pxarple  are  the 

same  as  those  shown  in  Example  1. 

F7 AMPLE  2:  TFF  LOGICAL  MESSAGE  TFBMTNATOF 
(Same  effect  as  Example  1) 

%SLEE 

E>OiNFW.file$AL? 

-creating  file  ”NEb .f ile"- 
I>  First  text  line$Second  text  line 
I>  Third  text  line$.$Ll,?$Q 

1  First  text  line 

2  Second  text  line 

3  Third  text  line 

Of 

/> 
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Note  that  In  the  fifth  line  of  the  above  example,  a  line  of 
text  was  inserted,  and  then  the  insert  mode  was  terminated  (by 
sending  a  message  consisting  of  only  a  delimited  by  tr.e 
logical  message  terminator)  and  "Edit  mode"  commands  were  then 
sent.  It  is  this  power  of  transmitting  multiple  messages 
delimited  by  a  reserved  key  which  allows  those  users  with  slow 
terminals  or  those  experiencing  long  data  transmission  delays 
over  the  network  circuits  to  effectively  use  the  editor. 

'“'any  persons  considering  the  editor  instruction  set  in 
Table  1  ask  how  it  is  possible  to  delete  lines  and  patterns  with 
this  editor.  These  functions  are  acomplished  with  the  use  ^f  the 
"replace"  functions,  replacing  the  items  to  be  deleted  with 
"nothing”.  In  the  context  of  this  editor,  a  "strirg"  consists  of 
a  sequence  of  characters  which  does  not  contain  any  cf  the 
logical  message  terminators.  Thus,  a  string  is  a  portion  of  a 
line  since  all  lines  terminate  with  a  <RETURN>  which  is  a 
terminator.  To  replace  portions  of  lines  one  uses  the  <R>eplace 
<S>tring  command,  while  the  <R>eplace  <L>ine  command  is  used  for 
larger  modifications.  For  example,  consider  the  file  created  in 
Fxarple  2:  supppose  we  wanted  to  delete  the  string  "text"  in  the 
first  line,  and  delete  the  entire  third  line.  Using  the  "RS"  and 
"PL”  commands  this  could  be  accomplished  as  shown  in  Fxarple  ?. 
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EXAMPLE  3:  DELETING  STRINGS  AND  LINES 


%SLED 

E>0$NEW.f 1 le 

-  3  lines  in  file  "NEW. file*'- 
E>L1 

1  First  text  line 
E>RS$text$$Ll 
1  First  line 
E>RL3$.$S1 

1  First  line 

2  Second,  text  line 
E>Q 

% 

In  the  above  example,  the  pattern  to  be  deleted  ir.  line 
number  one  was  replaced  with  a  string  consisting  of  no 
characters.  The  third  line  was  deleted  by  replacing  it  with  a 
null  line  (ie.  entering  INSERT  mode,  ar.d  exiting  -via  a  message 
consisting  of  only  a  period-  without  entering  any  data'.  In  much 
the  same  manner  the  desire  to  insert  text  "Before  Lire  r."  car.  be 
accomplished  with  commands  to  Insert  text  "After  Line  r-l” . 

SIED  Implementations  must  also  cushion  the  user  from,  his 
mistakes  (ie.  provide  "fail  soft"  features).  For  example,  a" 
attempt  to  open  a  non  exlstant  file  should  produce  an  error 
message  as  shown  in  Fxample  4. 

EXAMPLE  4:  Soft  Failure 

E>L1 

-no  text  file  open- 
E>0$NEV.f lie 

?  lines  ir  file  "NEW. file" 

E>Q 

% 


In  addition  to  the  normal  demands  of  defensive  programming. 


the  nature  of  the  editor  requires  that  careful  attention  be  paid 
to  error  detection  and  recovery.  The  variety  of  terrir.al  types 
and  line  speeds  requires  that  the  SLED  messages  be  both  riper 
and  concise.  The  minimum  set  of  SLED  advisory  messages  is  shcv>r. 
in  Table  2,  along  with  the  circumstances  which  will  cause  the" 
to  be  generated.  HI  implementations  must  detect  these 
situations  and  recover  gracefully.  Individual  implementations 
are  encouraged  to  perform  more  sophisticated  consistency  ''hecks 
for  abnormal  user  and  system  conditions. 

CONCLUS IONS 

Significant  increases  in  the  productivity  of  computing 
professionals  can  be  realized  if  we  can  rake  our  existing 
computer  resources  more  ”usabl°M .  The  ultimate  r.cal  -the 
creation  of  an  effective  and  uniform  man/computer  interface-  is 
perhaps  idealistic  and  unachievable.  There  are  however,  a  number 
of  areas  where  we  can  achieve  success,  and  make  more  efficient 
usage  of  our  human  and  machine  resources.  One  such  area  is 
uniformity  of  software  development  tools  in  distributed 
computing  systems. 

The  Standard  Line  EDitor  project  is  an  exreriment  in  this 
vein.  Several  testbed  implementations  of  STED  are  now  being 
written.  With  the  completion  of  these  orogrars,  and  with  the 
continued  support  of  the  Navy  Laboratory  Computer  Committee  and 
the  NI,CC  Software  Technology  Working  Group,  it  is  hoped  that 
SLED  may  be  Implemented  throughout  the  NALCON.  This  will  be  a 
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Table  1: 


SLED  Comma r.d  Summary 


COMMAND  FUNCTION 


USACi 


LINE  INSERTION  ANT  REPLACEMENT  COMMAS LS : 
insert  text  After  Line  number  n 
Insert  text  to  Replace  Lines  n  thru  m 
or.,  to  insert  text  to  Replace  a  single  Line,  r. 

STRING  REPLACEMENT  COMMANDS 
Replace  all  occurrences  of  String  "p"  with  the 
string  ”q"  in  lines  n  thru  m  inclusive, 
or....  *eplac;j  all  occurrences  of  String  "p" 
with  string  ”q"  in  line  n 
or....  Replace  all  occurences  of  String  ”p* 
with  string  "a"  in  the  current  line. 

STRING  SEARCH  COMMANDS 
Display  all  lines  containing  String  ”p" 
or...  Display  all  lines  between^l ines  n  and  u. 
inclusive  which  contain  string  ”p" 

OUTPUT  COMMANDS 

set  current  Line  to  n  and  display  that  line 
or...  display  the  current  line 
or...  display  Lines  n  thru  m  inclusive,  and  set. 
the  current  line  to  m. 

display  a  "Screen"  of  lines  (23  lines)  beginning 
with  line  n 

or...  display  a  Screen  beginning  with 
the  current  line 

display  Version  and  implementation  information 
display  <MVnu  of  editor  commands 

CONTROL  COMMANDS 

Open  or  Create  a  file  for  editing 

Cult  the  editing  session  and  update  all  files 

Change  the  message  Terminator 


ALr. 

(*' 

RLn  ,r 

(*' 

*Ln 

^Sn ,ripio i 

®Sr.$p$qi 

RSipiq* 

I  Sip* 

DSr  ,rr*pi 

In 

L 

In  ,m 

Sr 

S 

V 

M 

0 

C 

CY 


The  symbol  indicates  the  use  of  a  logical  message 

terminator,  not  the  <RETURN>  key.  (See  further  the  text  ard 
Figure  2. ) 

(*)  These  commands  cause  the  editor  to  enter  the  TFXT 
INSERT  mode. 
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Figure  1: 

Sample  output  from  <M>enu  command 


SLED  COMMAND 

LINE/TEXT  INSERT 


ALn 

insert  <A>fter  <L>ine  n 

PLn 

<R>eplace  <L>ine  n  .or. 

RLn,m 

lines  n  thru  m 

OUTPUT 

COMMANDS 

L 

display  current<L>ine 

Ln 

or  line  n, 

Ln  ,m 

lines  n  thru  m 

S 

<S>how  a  "screen"  of  lines 

Sn 

show  a  screen  about  ln  #n 

M 

show  command  <'M>enu  (this) 

V 

show  <V>ersion  information 

TO  <Q>UIT  TEE  EDIT  TYPE  "Q<ret>" 


SUMMARY 

STRING  RFPLACEMFNT 
RS$p!iq$  '  ^^eglace  ^FMring 
RSn$p$q^  ”p  with  "q”  in 
RSn,n$piq$  inidcated  lines. 
STRING  SFARCE 

DS$p$  <DMsplay  lines  vt 

string  V, 

DSn,m$p$  or  show  any  lines 
n-rr  containing  ”p” 
CONTROL  COMMANDS 
0  ^Oper  a  file  or 

create  e  file  for  editing 
CT  <C>hange  the  lcgiral 
message  <T>ermir.ator 


Figure  2: 

Sample  output  from  <V>ersion  Command 


SLED  Version  Pasl.l  NPS-Mcnterey  630503 
Local  Expert  is  J.  Doe  406-646-2449  0600-1600  PST 

LINE  DELFTE  KEY  is  <C0NTR0L-U> 

CHARACTER  DELETE  FEY  is  <RUROUT>  (also  called  DELETE  / 

EDITOR  LOGICAL  MESSAGE  TERMINATORS  ARE: 

(1)  <RETURN>  and  (?)  <ESCAPF>  (echos  "$' ) 
**  the  message  terminator  can  NOT  he  changed  tc  'Line-Feed'  ** 

Local  System  supports  UPPER/lover  case 

Local  System  DID  NOT  require  deviation  fm  SLEE  standard. 


4 
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Table  ?: 


SLED  Minimum  Advisory  Messages 


Message 


Sltuatior  and  Editor  resporse 


-invalid  command- 

in  command  mode  an  unrecognizable 
command  was  issued  < or  an  ambigious 
delimiter  was  used.) 

-n  lines  in  file  "f  "- 

an  <0>pen  command  on  file  "f"  completed 
successfully. 

-creatlng  file  "f"- 

tried  to  <0>pen  file  "f",  which  did 
not  exist.  A  new  file  is  created. 

-closing  file  " t" - 

an  <0>pen  command  was  issued  with(>e 
file  already  open.  This  file,  ”f" 
is  updated  and  closed,  and  the 
command  proceeds  normally. 

-"o  text  file  open- 

an  edit  command  was  executed  without 
a  text  file  open. 

-co  string  found- 

a  "RS"  or  "IS"  command  was  issued, 
and  the  search  string  was  not 
found . 

old  string?> 

(A  prompt)  A  "RS"  or  "DS"  command 
was  issued  and  the  first  string 
was  not  specified.  The  editor  new 
waits  for  the  string  to  be  entered 

new  string?> 

(A  prompt)  A  "RS"  command  was  issued 
where  the  second  string  was  not 
specified.  The  editor  now  waits 
for  the  string  to  be  entered. 

file  name?> 

(A  prompt)  Ar.  <o>pen  command  was 
issued  without  specifying  the  name 
of  the  file.  The  editor  now 
waits  for  the  file  name  to  be 
entered . 

terminator?> 

(A  prompt)  A  <C>hange  ^^ermi ra tor  comma 
was  issued.  A  valid  ASCII  character  i 
entered  to  act  as  a  nessage  terminator 
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